Real time auction with end game

ABSTRACT

A real time auction system operates in a non real time mode, and an end game mode in which the users are placed in a forum. In both modes the users are capable of placing bids along with times when those bids should be executed. An agent treats the bids as secret until the time, and then at the time executes those bids.

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of the U.S. ProvisionalApplication No. 60/169,728 filed on Dec. 8, 1999 and U.S. applicationSer. No. 09/669,805, filed Sep. 26, 2000.

BACKGROUND

[0002] The present invention describes a new paradigm for conducting anauction on a remote information server such as the Internet.

[0003] The Internet is an extremely powerful tool for conductingauctions. Literally millions of users can simultaneously take part in asingle auction. Auction sites such as E-bay have popularized theInternet auctions. Each of these auctions allows bidding betweenvirtually every person who has access to the Internet.

[0004] The auctions often last over an extended period of time, e.g.over one week. Many of these auctions use agents which automaticallyhandle the bidding. The bidder instructs the agent with informationabout the bidder's maximum desired bid. The agent will bid only up tothat amount. Moreover, the agent does not immediately bid its maximumamount; it only bids an amount when the price of the item rises to alevel that forces the agent to bid in order to keep the high bid.

[0005] It has been found that the most serious and competitive biddingcan occur at the end of the auction. Conversely, bidding early in theauction tends to cause the product to sell for more money than it wouldhave sold for otherwise. Therefore, people often wait until the lastinstant, e.g. the last minutes or seconds of the auction, beforebidding.

[0006] Auction sites such as E-bay often have fixed times for theauction ending. The auction ends at that moment, even if bidding may bemost intense at that moment. If a bid is placed, but not received beforethe instant of the auction end, the item will sell. Therefore, Internetdelays can cause a product to sell for less money than it otherwisewould have sold for.

SUMMARY

[0007] The present invention recognizes that the standard model ofInternet auctions is actually flawed. Auctions should be carried outmore like a real live auction. While live auctions are known in theInternet art, a different kind of live auction is described herein. Thislive auction includes certain refinements which improve it for use onthe Internet.

[0008] This includes an identification system with each of a pluralityof bidders being identifiable.

[0009] Another aspect includes a combination of an on-line auction andoff-line auction, with the off-line auction forming effectively adisplay period for the merchandise during which the users can placebids, and the on-line auction forming a final bidding period for thegoods during which the goods are actually sold.

[0010] Another aspect is an agent for use in an online auction, in whichnot only the amounts of the bids, but also the time when those amountsare release, are specified.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] These and other aspects will now be described in detail withrespect to the accompanying drawings, wherein:

[0012]FIG. 1 shows a block diagram of the hardware used by the biddingsystem of the first embodiment;

[0013]FIG. 2 shows a flowchart of operation according to a first mode;

[0014]FIG. 3 shows a flowchart of the special “agent” used in thisauction system;

[0015]FIG. 4 shows a flowchart of operation of an end game;

[0016]FIG. 5 shows a diagram of the forum showing the multiple users

[0017]FIGS. 6A and 6B shows flowcharts of bidding;

[0018]FIGS. 7A and 7B show a quick bid embodiment; and

[0019]FIG. 8 shows an embodiment that may prevent last minute bidding.

DETAILED DESCRIPTION

[0020]FIG. 1 shows a basic structure of a first embodiment of thebidding system. The bidding is actually carried out within a virtualenvironment created by the central “server” computer 100. The server maybe more than one computer, which operate to execute a program asdescribed herein.

[0021] Server 100 keeps track of all the bids, and produces thegraphical environment that is displayed on each of the remote terminals,where only three remote terminals: 110, 120 and 130; are shown.Literally every computer on the Internet could be included. Each of theremote terminals preferably obtains a view that is partly the same asthe others, and partly different.

[0022] Server 100 runs the flowchart shown in FIG. 2. The main flowchartruns the beginning part of the auction as a conventional Internetauction, shown generally as step 200. The item to be sold is displayed.It is listed in some kind of index, or under a category. This can bethought of as the advertising part. Using an analogy to a real auction,this is the portion of the auction where the items can be viewed.

[0023] In a particularly preferred embodiment, the item is viewed inthree dimensions. A picture of the item is shown. The picture of theitem can be a two-dimensional picture or a three-dimensional picture. Ifa three-dimensional picture is used, the system first displays atwo-dimensional “splash” of the image while the system is loading thethree-dimensional information. The three-dimensional information is thenused to enable viewing the item three-dimensionally. This can be doneusing the techniques described in our application entitled “Touch andFeel on the Internet”; Ser. No. 09/505,646.

[0024] In whatever form the item is displayed, this is the period duringwhich the users can see and find the items of interest. As conventional,this portion of the auction also accepts bids, e.g. via a bid agent. Aspecial bid agent can be used as described herein.

[0025] This bid form continues until some specified time period (X)before auction close, e.g. one hour prior to auction closing. Step 205shows detecting that predetermined time, shown as time T−X. The auctionmode changes to a mode that indicates the higher energy and interestassociated with this portion of the auction. Step 210 shows calling the“end game”, which is the routine that runs this higher energy portion ofthe auction. This changes the auction mode to a more interactiveatmosphere.

[0026] At step 220, all of the people who have registered for theauction and indicated a desire to participate in the end game are sent amessage. This message can be sent in a number of different ways. Ane-mail can be sent to each person on the list. Pager numbers can also becontacted to leave an alphanumeric page indicating the URL of theauction site. These two techniques are especially advantageous when theemail or page is sent to a cellular phone of a type that allows webbrowsing. The endgame can be carried out on the cellular phone, byclicking on the URL that is sent.

[0027] An automated agent can leave an audio message (voice mail) on aperson's normal telephone, indicating that the end game has started.

[0028] After an endgame has started, and while still in progress, a usercan log into the auction site. The user enters their name and password,as conventional. Upon entering their name and password, the userreceives an indication, e.g. via a pop up window with a prompt, that theend game for this auction is in progress. The pop up window can takethem directly into the end game environment.

[0029] The special agent program used herein takes into account therealities of such a system. Bidding too early in the process canincrease the price for an item. Usually the prices in the early part ofthe auction are kept moderate. The bidding often does not reach levelsapproximating the actual value until later in the auction.

[0030] The previously-used system automatically immediately made its bidbased on current bid amount. If two people gave instructions to theirsystems, those two people would automatically and immediately bidagainst each other, until one was outbid. Consequently, users often donot place their bids early, to avoid starting such a bidding war.

[0031] The present application describes an agent which avoids thisissue by using a time profile. The agent allows setting bids, includingmaximum bids, and also setting times at which those maximum bids will beprovided.

[0032] Another operation describes a graphical user interfacesimplifying that operation.

[0033] The flowchart shown in FIG. 3 represents the agent manager(AGENT_MG).

[0034] The user is first prompted for a maximum bid (MAX_BID) at step301. That maximum bid indicates the maximum that the agent will beauthorized to bid on the item. The agent will not bid any amount,however, until authorized to do so.

[0035] At step 310, a graphical representation of times and the maximumbid is displayed. The graph can initially show any desired profile ofbid vs. time; here it shows the agent being authorized to bid theMAX_BID amount, immediately. This profile, however, can be changed. Step320 shows one technique in which the graph is edited. The user may, forexample, not allow any bids until the end game or allow a very moderatebid initially, and more bids in the end game. The profile as edited instep 320 shows no bids being authorized until a time y. That time y canbe determined with precision by resting the cursor over a time, andwaiting for a “screen tip” to be displayed. This graphical system can beeasily edited on many different platforms, e.g., a cellular phone thatallows web browsing.

[0036] At any point, instead of using the graphical user interface, theuser can select, e.g., right click, on a portion of the line, and use atext entry system. Step 330 shows a textual interface. The user canenter information, e.g.,

[0037] AT TIME t1,

[0038] ALLOW A MAXIMUM BID OF $x1, where the underlined information isentered.

[0039] However entered, the maximum bids and the times at which thosemaximum bids are allowed to be released, are stored at 340. Thisinformation is entered as a function of time, and hence can be stored asrules, for example. A rule might read:

[0040] At time AUCTION_END −0:30 (30 minutes before auction end), bid upto $10.

[0041] Option entry is carried out at step 350. Options can include:

[0042] Overriding previous bids during the end game. This can beimportant with an agent. If the agent has been instructed to bid up to$20, a later bid may actually bid against the agent's previous bid, andforce the agent up to its maximum. This system enables overridingprevious bids placed with the agent, in order to allow placing a higherbid. In some instances, that overriding can be allowed, for example,only when a higher bid is desired.

[0043] The ability to cancel a previously-entered rule.

[0044] Contact information to contact (at step 220) during the end game,and/or a request to enter the end game.

[0045] Authorization to automatically raise the bid for a reserveauction.

[0046] Other options are possible.

[0047] Each of these options are preferably written as rules that drivethe automated bidding program.

[0048] These rules written by the agent are kept secret until the timethey are executed. Each of the rules includes an execute time. Forexample, for the bid rules shown in step 330, each rule starts with attime t₁, do x. The present application contemplates placing multipledifferent bid/time combinations in this way. For example, a first onecould allow bidding up to $x1 at time t−1 hour; and a larger bid of upto $x2 at time t−½ hour.

[0049] Prior to this time to execute, the main process running on theserver computer cannot obtain the contents of the rule. Only the personwho made the rule can read the rule.

[0050] After the time t₁, the agent will bid up to the maximum amountspecified, not placing any bid until the time specified. However, sincethe time for the rule has passed, the server at that point knows certaininformation about the contents of the rule, and can use that informationas described herein.

[0051] Therefore, before the specified times, the rules are absolutelysecret. No one except the bidder can find these rules. After the time,the contents of the rules can be known to the server. The disclosureprovided herein describes how these bids allow faster bid processing,e.g. bid rejection and the like. Step 360 shows the agent generallycarrying out a time processing routine. At the specified time, each rulee.g. bid, is released.

[0052] For rules such as reserve handling, the time of release is theauction end.

[0053] As described above, at the specified time, AUCTION_END−X, the endgame routine is called, and the auction form changes. The end game isshown in FIG. 4. Step 400 detects a new bidder entering the end game. Asdescribed above, this can be done by the bidder signifying theirintention to enter the end game, or can be an automatically-created popup window when a previously-registered user logs in to the auction'swebsite. The flowchart shows verifying the identity of the new bidder atstep 402. Once the identity is verified, e.g., by username and password,the user is added to the participants list for the end game at step 404.

[0054] The endgame is carried out in a graphical forum. Each user isshown in the forum, along with other users. The forum 500 is shown inFIG. 5. Once the new user has been added at step 404, the user isdisplayed in the forum, with an icon indicating the user's status. Thestatus can include credit rating or other information. The user isinitially displayed in the new bidder area 510. Step 406 illustratesdisplaying the new user in the new bidder area.

[0055] In this embodiment, the user signs in, and thereafter can placebids without entering their name/password. This is different from otheronline auction paradigms, in which each bid requires the user'sname/password. This is more difficult for the user, and also slows downthe operation. In this paradigm, a session key can be established afterlogin, so that the communication occurs over a secure channel.

[0056] The check ID step of step 402 can be user verification by anymeans. One such verification is specific to use with a web-browsingcellular telephone. The caller ID of the calling telephone can beestablished. This establishes the user's identification automatically.

[0057] One feature of this real time auction is that the bidders mustreceive information that is frequently updated. Typical web browsers,however, do not automatically update the information that they display.Accordingly, the present application uses automatic information updateto provide up to date information to the bidders.

[0058] This automatic information update can be done in different ways.One way is to send an update command to the browser at specifiedintervals. This update command causes the browser to request a refresh,thereby loading the new and updated forum scene.

[0059] In another aspect, certain parts of the image that is displayedby the web browser to represent the forum are defined as being streamingvideo. Streaming video is well known in the art, and displays acontinuous stream of video to the user. A standard streaming videostream can be used.

[0060] Another option defines a special object within the web browserenvironment. This object is effectively stop motion video. At times theobject can be changing. When unchanged, the object remains the same.When the object receives information, it changes, without a need to“refresh”.

[0061] In any case, assuming that the standard web browser is used, acommand is sent to the web browser at step 408, requesting at least thenew bidder's web browser to refresh. The new bidder sees himself addedto the new bidder section 510. Others might not see this addition untilsome other action causes them to refresh. However, a new bidder beingadded is not necessarily important to all bidders.

[0062] The add to participants list at step 404 includes assigning anagent to the participant at 405, if necessary. The participant mayalready have an agent assigned from previous participation in theauction during the display mode 200. If so, the user retains that agent.If not, a new agent instance is defined, e.g. by auction number andagent number. The agent is assigned one-to-one with the user so that theuser has his own agent. As described above, that agent can keep secretsduring the bidding process, even though that agent may be running withinthe same server that runs many of the other agents.

[0063] Also, after the ID is verified at 402, the user name is displayedalong with the results of the id check. For example, the system mayoperate a rating system for users. This rating system may include acredit rating of the user, for instance a maximum bid that the user isauthorized to make.

[0064] Another rating is based on the user having entered a guarantee ofbid. For example, the user may use a credit card as part of the bid/bidprofile process. When the bid is accepted and the auction is ended, thatcredit card is automatically charged for the bid amount.

[0065] Another option forces the user to post a bond, and can charge theauction against that bond in case the bid is not satisfied.

[0066] Yet another possibility is that other participants rate the oneparticipant, and provide a rating scheme that depends on the numberpositive and negative comments. This is similar to the rating schemeused by E-bay™. According to all of these systems, the user's name asdisplayed at step 406 may include an indication of the users rating.

[0067] Therefore, the user may be displayed as:

[0068] JOE BLOW;

[0069] RATING A;

[0070] BOND POSTED

[0071] until the amount of the bid reaches the amount of the postedbond. After the bid exceeds the posted bond, the display can say:

[0072] JOE BLOW;

[0073] RATING A;

[0074] BOND AMOUNT EXCEEDED

[0075] If a credit card is used, the display can say

[0076] CREDIT CARD ON FILE.

[0077] Another option displays information about the user in color basedon the rating. A green rating means that the user has a good creditrating. A blue rating means a guaranteed bid. A red rating may mean thatthe credit line is exceeded.

[0078] At step 420, a new bid is detected. Step 422 obtains the amountof the new bid. At step 424, the bidder who placed the bid is moved tothe “current bids” area 520. The AGENT_WIN routine (described hereinwith reference to FIGS. 6A and 6B) is called at step 426. The currentbid amount is fed to this routine to determine if the current bid is awinner, and to take action based thereon.

[0079] The agent win routine can be done in one of two different waysshown in FIGS. 6A and 6B. These depend on the way that the systemhandles bids.

[0080] A number of variables are defined associated with the biddingprocess.

[0081] NEW_BID is the amount of a newly-placed bid.

[0082] MIN_BID is the minimum amount that needs to be bid to place abid. This value is related to the current bid (CURR_BID), and thebidding increment (BID_INC).

[0083] WIN_BID is the amount that is necessary to win the currentauction (until outbid). This value may or may not be known to the localagent.

[0084] The local agent is partially resident on the client computer,e.g., as an applet running on the client computer. This is done to allowfaster reaction to bids. Preferably at least a part of the agent, runson the users terminal. This part of agent includes certain numbers whichfacilitate accepting or rejecting bids. For example, the applet iscontinually updated with minimum bid amounts and, to the extentpossible, with winning bid amounts. During the end game, when the userplaces a bid, the agent is able to accept or reject the bidsubstantially immediately. Then the agent can send a specified signal tothe mainframe computer that is actually moderating the bid. Thespecified signal can include an indication that an acceptable bid isfollowing. This can substantially speed the process, since an indicationof an acceptable bid can be quickly sent and received by the clientcomputer.

[0085]FIG. 6A is executed when the maximum among the released bids areknown to all agent applets. The new bid is detected at step 420. Allagents are continually updated with MIN_BID, WIN_BID, CURRENT_BID atstep 610. At step 612, all the values are updated to all participants.

[0086] At step 614, the current bid (CURR_BID) is compared with thevalue of the winning bid (WIN_BID). If the current bid is found to beless than the winning bid at 614, a message is returned to the userplacing the bid, indicating “outbid” at 620. The current bid is also setto the value of new bid at step 625, thereby increasing the new minimumbid (=CURR_BID+BID_INC).

[0087] These new variables are sent to the mainframe, and at steps610/612 are sent to all agents. All agents therefore store the valuesfrom which it can be immediately ascertained whether a locally-placedbid will win or not.

[0088] If the new bid is greater than the winning bid at step 614, thenthe new bid becomes a winning bid at step 630. The current bid is set tothe value of the winning bid at step 630. Note that the current bid isnot set to the new bid, unless the new bid=the winning bid. Instead theagent manager is called as described below. At step 635, the new amountis displayed, and the bidder is moved to the top of the screen showingthe forum. The system also sends a global update, to update all users toindicate a new winning bid, and a new order of users. Thepreviously-winning bid is placed to the current bidder's area.

[0089] If the new bid is greater than the winning bid at 640, the agentmanager is called at 645 to define the bids to be released as a functionof time.

[0090]FIG. 6B shows the alternative in which the winning bid variable isnot known globally to all agents. In this case, a new bid at 420 causesa test to be made at step 650 to determine if the current bid is greaterthan the minimum bid. If so, the minimum bid is posted to the agentholding the winning bid (AGENT_WINBID) at step 655. AGENT_WINBIDdetermines, from its rules database, if it is authorized to place a bidthat is high enough to win at the present time, at step 660. If so, thenthe current bid and minimum bid variables are appropriately increased atstep 665, and a notice of outbid is returned at 670. If AGENT_WINBID isnot authorized to bid high enough, then the current bid variable is setto the new value at step 675, and the process returns an indication thatthe current bidder is now the winner. All variables are updated and sentto the mainframe for sending to all agents. The new bidder's agent alsobecomes the new AGENT_WINBID at 680. An update is posted globally at685.

[0091] The difference between the two routines is the amount ofinformation held locally. In the FIG. 6A routine, all agents haveinformation allowing them to determine locally whether any bid will win.The do not necessarily display it, but they store the information. Theycan accept or reject a bid locally.

[0092] In the FIG. 6B routine, the agents keep the bids secret. A bidcan be posted to the agent holding the bids to determine if there is awinning bid. However, this takes longer to effect.

[0093] In both routines, the information is not available at all beforethe scheduled release time.

[0094] Returning to FIG. 4, step 430 illustrates that the time forauction is about to expire. This may happen, for example, at the time ofauction expiration or 2-10 minutes before. The first thing that happensat step 432 is the global display of the word “going . . . ”. This islike a real auction, where the auctioneer warns the audience with thiskey word. In this embodiment, the word may be displayed in a ballooncoming from the auctioneer's or agent's mouth, as shown in the forum ofFIG. 5. An update is sent at 434, so that all users will see thismessage. Alternatively, a new streaming video object is defined comingfrom the auctioneer's mouth so that the users see the “going” symbol. Atthis point, time is of the essence. Another paradigm becomespossible—the quick bid paradigm.

[0095] The quick bid is shown in FIGS. 7A and 7B. Again there are twomodes for the quick bid. In one mode, the agent knows all values. Inthis case, the agent can enable not only posting a quick bid, but alsoposting a quick winning bid. The agent in FIG. 5 shows the options forbidding when they are available. For instance, the quick bid 530 may bedisplayed as shown in FIG. 5, along with the quick winning bid 535.Passing the cursor over either value displays a “screen tip” that allowsthe user to view what the quick bid or quick winning bid amount will be.Since these values are known to the agent, they are stored in the localbrowser, and can be displayed quickly. The quick win bid may bedisplayed or not displayed, depending on rules, options andcircumstances of the auction. In one mode of operation, users areprovided with an incentive to share the winning bid with others. Forinstance, users may get a discount or other incentive to allow the quickbid to be known. Even if the quick bid quick win is known, it may onlybe allowed during the going, going, gone, during which time emotionsbecome higher.

[0096] The quick winning bid is also shown in FIG. 7B. In either case,when the user clicks on the amount, they receive an instantaneousindication of the amount they have bid and a confirmation. By clickingyes, the bid is instantly posted, hence stopping the going, going, goneprocess for at least one minute as illustrated in step 440. After nofurther bids have been received, the moderator once again enunciates thegoing (step 432), beginning the end of the process. This can enable thequick bids as described above.

[0097] In a normal auction, enunciating the first word “going” would bequickly followed by another going. However, in this auction, the systemmust allow time for users to get their bids in over the Internet. Hence,preferably at least thirty to sixty seconds elapse prior to the secondgoing at 445. After each instance of going, a global update is sent at450 or the going going gone is displayed in streaming video. Afteradditional time has elapsed at step 452, without additional bids beingdetected at 454, the item is indicated as sold at 460.

[0098] Other embodiments are contemplated. For example, while thepresent application describes doing this operation on the Internet, thesame operation could be applied to any remote information server ornetwork. The present technique refers to an auction, where the termauction is intended to include any forum in which bids can be placed,one bid which is higher than the bid before it, excluding other bidswhich may be lower. However, a “dutch auction” in which multiple highestbidders obtain the information, is also contemplated. The presentapplication describes a few different ways of automatically updating theremote servers. It should be understood that other techniques ofautomatic update of the remote servers are also possible. In addition,the present application contemplates in some circumstances that some butnot all of the remote servers will be updated.

[0099] Another aspect of this system is shown with reference to FIG. 8.The present application has described what amounts to two oppositescenarios. A first scenario is based on the user's desire to place thebid as late in the auction as possible. By doing this, the bidder mayattempt to avoid a bidding war. In an eBay type auction with a fixedending time, this means trying to get the bid placed as close to thelast instant as possible. Of course, this exact same scenario may be badfor the seller. The seller may want to create a bidding war. Therefore,the above has described a system with a variable ending time to theauction; and/or an endgame.

[0100] The technique of waiting until the last instant to place the bidhas been titled “sniping”. Sniping may be advantageous for the buyer,since it avoids a bidding war, and may keep the price lower. However,the sniping bidder does place a higher bid at the last instant, henceincreasing the total amount of money that the seller receives. When antisniping techniques are used, a bidder may be motivated to place theirbid earlier in the auction. This may inevitably be in the seller's bestinterest. This embodiment discloses a way to make sniping less desirablefor the buyer.

[0101] The system as disclosed herein runs the flowchart shown in FIG.8. In this flowchart, at 799, the seller selects anti sniping andspecified options associated with the antisniping. At 800, normalauctioning procedures are carried out. As part of the normal auctioningprocess, bidders' bids and identities are recorded. Those recorded bidsand identities may be used for the anti sniping techniques describedherein.

[0102] One antisniping parameter entered at 799 is the time option. Thistime corresponds to the time-to-auction-end. The system detects thistime, an “endgame”, at 805. This may be the same endgame that asdisclosed in the previous embodiments, or may be a different endgame..Preferable times for the endgames may be between the last 2 minutes ofthe auction and the last 2 hours of the auction, for example, althoughany time could be used.

[0103] At 815, a user attempts to place a bid within this anti snipingendgame. The identity of the new bidder is compared against the list ofprevious bidders. That is, the identities of those users who attempt toplace the bid during this time are compared against the latest bidsaccumulated during the normal bidding process at 800. If the new bidderis on the list at 815, the bid is allowed to continue as normal at 820.If the new bidder is not on the list at 815, then an antisniping actionis taken at 825. The antisniping action at 825 can be many differentoptions described herein. In one embodiment, only bidders whose namesare on the normal bidding process list are allowed to place bids duringthis final antisniping endgame. Therefore, bidders can not simply waituntil the last moments of the auction to place the bid.

[0104] In one embodiment, bidders can simply place of bid any time inthe auction prior to the endgame to get their name on the list compiledat 800. This would avoid the antisniping action at 825. One possibledisadvantage of this is that a bidder may be encouraged to place aminimum bid during the auction, to simply get on the bidders list.

[0105] Another embodiment at 801 compiles a list of only allows thosebidders who were previous-winning bidders as the anti sniping list. Thisforces serious bidders to place a serious bid earlier in the auction tobecome a winning bidder sometime earlier in the auction. In theembodiment using operation 801, only early winning bidders become exemptfrom the anti sniping action 825.

[0106] Yet another embodiment counts only winning bidders during a lasttime period of the auction, e.g., during the last 2 hours of the auctionon the list that qualifies for exemption from anti sniping. Yet anotherembodiment counts no one on that list—all bidders placing bids at thelast minute are subject to anti sniping actions, whether they werewinning bidders previously or not. This is the furthest action inencouraging users to place their full-value bids early.

[0107] Another aspect of this system contemplates taking different antisniping actions. This allows “sniping” bidders, however determined, toplace a bid. However, these bidders are considered on an unequalfloating with other bidders. For example, many systems including eBayuse an agent to make sure that the bid which is placed stays at thelowest bid necessary to win, even if a users maximum bid may be higherthan this lowest bid needed to win. One example of the system which mayprovide an unequal footing for sniping bidders is to prevent snipingbidders from using this agent. If the winning bid is $500, for example,a user may place the bid of $700. If the agent is used, and the lowestvalue needed to win the bid is $505, then the bid which is placed willbe $505, even if the user's maximum bid is $700. However, with theunequal footing system, when the user places the bid, it willautomatically be placed at the maximum. Therefore, a user placing thebid at $700 will automatically be bid at $700, even if that amount isnot needed to win the bid. This may produce advantages, since itseriously discourages these last minute bids. If they are made, theseller may secure advantages from this, since the bids will be higher.

[0108] Other anti sniping actions are contemplated.

[0109] The use of the anti sniping agent, and it's options, may be setby the seller at 799. The seller may set these options when they arelisting their product for sale.

[0110] All such modifications are intended to be encompassed within thefollowing claims, in which:

What is claimed is:
 1. A method of conducting an auction over a network,comprising: displaying an item which will be the subject of an auction,said displaying comprising providing a view of the item over thenetwork, which allows the item to be viewed from at least multipledifferent perspectives; and accepting bids for purchase of the item overthe network.
 2. A method as in claim 1, wherein said providing a viewcomprises allowing the item to be viewed three-dimensionally.
 3. Amethod as in claim 1, wherein said providing a view comprises firstproviding a first resolution view of the item, and loading views fromsaid at least multiple perspectives while the first resolution view ofthe item is being displayed.
 4. A method as in claim 3, wherein saidmultiple perspectives include a three-dimensional view of the object. 5.A method, comprising: allowing each of a plurality of users to submitbids for a specified item being auctioned, said bids being submittedfrom any of a number of clients over a network to a server whichcollects said bids; and defining rules for actions in said auction, saidrules including at least a time when the action will take place, and anactual action that will take place at the defined time.
 6. A method asin claim 5, wherein said actions are bids to take place at the definedtime.
 7. A method as in claim 5, wherein said actions are allowingoverride of a previous bid.
 8. A method as in claim 5, wherein saidrules are kept secret until the defined time.
 9. A method of conductingan auction over a network, comprising: for any particular auction,sending information from a server computer to a local computer, whichinformation enables the local computer to carry out some functionassociated with bidding on an item; making a decision at the localcomputer to accept or reject a new bid from a user at the localcomputer; and only if the new bid is accepted at said local computer,sending information about the new bid to the server computer.
 10. Amethod as in claim 9, wherein said information includes informationabout a bid amount which will be necessary for the user at the localcomputer to be a highest bidder, and wherein said accepting a bidcomprises comparing a local bid to said highest bid information, andsending said information to said server computer only when said localbid is higher than said highest bid information.
 11. A method as inclaim 9, further comprising automatically updating each of a pluralityof computers with new information.
 12. A method of conducting an auctionover a network, comprising: displaying an item for sale on each of aplurality of client computers associated with the network, based oncommands from a server computer; accepting bids from any of the clientcomputers, and communicating information about accepted bids to saidserver computer; and wherein said displaying comprises displaying awinning bid amount which allows a user to automatically become thewinning bidder.
 13. A method as in claim 12, wherein said winning bidamount is an amount higher then a current minimum bid amount.
 14. Amethod as in claim 12, further comprising automatically determining anaction which represents change in an auction condition, andautomatically updating said displaying to change based on saidautomatically determining.
 15. A method, comprising: displaying an itemfor sale by auction over a network; and allowing entering either a bidfor said item, or an amount that automatically wins the auction.
 16. Amethod as in claim 15, further comprising automatically updating atleast parts of the display seen by a plurality of users indicative ofthe item for sale.
 17. A method as in claim 15, wherein said displayingan item for sale comprises displaying a three-dimensional view of theitem for sale.
 18. A method as in claim 15, further comprisingdisplaying a screen tip indicating bid amounts.
 19. A method as in claim15, wherein said network is the Internet.
 20. A method, comprising:displaying an item for sale over the Internet, by causing said item tobe displayed on each of a plurality of client computers associated withthe Internet, based on commands from a server computer; and displayinginformation associated with the bid for the item in a screen tipassociated with the item when a cursor is placed over the item on one ofthe client computers.
 20. A method as in claim 19, wherein saidinformation associated with the bid for the item is a current bidamount.
 21. A method as in claim 19, wherein said information associatedwith the bid for the item is a bid amount, and further comprisingallowing the user to accept a bid amount associated with a screen tip.22. A method of conducting an auction over a network, comprising: forany particular auction of an item, sending information to a plurality oflocal computers which enables the local computers to carry out somefunction associated with bidding on the item; displaying saidinformation on said local computers; automatically updating saiddisplaying on each of said plurality of computers with new information.23. A method as in claim 22, wherein said automatically updatingcomprises automatically refreshing a Web browser running on computersassociated with said at least some of said plurality of users.
 24. Amethod as in claim 22, wherein said automatically updating comprisingusing streaming video to form certain parts of said view.
 25. A methodas in claim 22, wherein said automatically updating comprises using stopmotion video to form certain parts of said view.
 26. A method as inclaim 22, further comprising determining an action representing a changein an auction condition, and wherein said automatically updating isresponsive to said determining.
 27. A method comprising: conducting anauction over a network by accepting bids for items, and establishing ahighest bid for an item as being a winning bid; and treating a bidreceived within a predetermined period of time before an end time of anauction less favorably than bids received prior to said predeterminedperiod.
 28. A method as in claim 27, further comprising allowing aseller to select an amount of time defining said predetermined period.29. A method as in claim 27, further comprising determining a bidreceived within said predetermined period of time that was placed by abidder who has previously participated in other bids prior to saidpredetermined period of time, and not treating said bid by said bidderless favorably.
 30. A method as in claim 27, wherein said conductingcomprises accepting bids in a first way which keeps bids at a low levelless than a maximum bid but high enough to win a specified auction, andsaid treating comprises accepting bids at a maximum amount withoutkeeping them at said low level.
 31. A method comprising: conducting anauction over a network by accepting bids for items, and establishing ahighest bid for an item as being a winning bid; determining identitiesof bidders bidding during said conducting; and treating a bid frombidders whose identities have not been determined by said determining,and which bids are received within a predetermined period of time beforean end time of an auction, less favorably than bids received prior tosaid predetermined period.